Capítulo 25 - Gestión de la Configuración
Software systems are constantly changing during development and use:
La gestión de la configuración comprende políticas, procesos y herramientas para gestionar los cambios en los sistemas de software.
Propósito: Evitar perder tiempo en modificar versiones incorrectas del sistema, entregar la versión incorrecta a los clientes o perder el código fuente de una versión del sistema o de un componente.
The configuration management of a software system product involves:
Agile development, where components and systems are changed several times a day, is impossible without using CM tools.
The development of a software product or custom software system takes place in three distinct phases:
La gestión de la configuración se basa en el principio de inmutabilidad (por ejemplo, la información congelada no se puede modificar más), lo cual implica la existencia de versiones, y provee mecanismo y técnicas para que un equipo de personas pueda trabajar de forma coordinada.
Es el proceso de realizar el seguimiento de las diferentes versiones de los componentes de software o ítems de configuración y los sistemas de los cuales forman parte. Y de asegurar que los cambios realizados por distintos desarrolladores a estas versiones no interfieran entre sí.
Puede verse como el proceso de gestión de líneas de código (codelines) y líneas base (baselines).
Codeline: una secuencia de versiones de código fuente donde se tienen las versiones más recientes en la secuencia derivadas de las versiones anteriores.
Baseline: es una definición de un sistema específico.
Difference between codelines and baselines:
La línea principal es una secuencia de versiones del sistema desarrolladas a partir de una línea base original.
Los sistemas de control de versiones identifican, almacenan y controlan el acceso a diferentes versiones de los componentes. There are two types of modern version control system:
Key features of these systems include:
En este modelo todas las funciones de control de versiones ocurren en un servidor compartido.
Si dos desarrolladores tratan de cambiar un mismo archivo al mismo tiempo, y sin un mecanismo de acceso, uno podría sobreescribir el trabajo del otro.
Se basa en: File locking y Version Merging.
Se basa en la reserva de recursos de forma explícita cuando sabemos que vamos a modificarlos.
Existen operaciones para reservar un archivo en modo escritura (check out) y liberarlo luego (check in).
El resto de los desarrolladores solo acceden en modo lectura
Tienen un enfoque de manejo de versiones entre pares (peer-to-peer).
En lugar de existir un repositorio en el cual sincronizan clientes, aquí las computadoras sincronizan entre sí.
No hay una copia canónica del código.
Menor riesgo de pérdida de datos.
Distributed version control is essential for open-source development where several people may be working simultaneously on the same system without any central coordination.
Es el proceso de crear una versión completa y ejecutable del sistema mediante la compilación y el linkeo de sus componentes, librerías externas, archivos de configuración, etc.
Involucra hacer check-out de versiones de componentes que se encuentran en el repositorio gestionado mediante el sistema de gestión de versiones.
System-building tools and version control tools must be integrated as the build process takes component versions from the repository managed by the version control system.
System building involves assembling a large amount of information about the software and its operating environment. Therefore, it always makes sense to use an automated build tool to create a system build:
Tools for system integration and building include some or all of the following features:
The build script is a definition of the system to be built. It includes information about components and their dependencies, and the versions of tools used to compile and link the system.
Three different system platforms may be involved:
Agile methods recommend that very frequent system builds should be carried out, with automated testing used to discover software problems. Frequent builds are part of a process of continuous integration as shown below.
The steps in continuous integration are:
The advantage of continuous integration is that it allows problems caused by the interactions between different developers to be discovered and repaired as soon as possible.
Bastante malo para sistemas muy grandes o complejos. O cuando la plataforma objetivo es diferente a la plataforma de desarrollo.
Si no es posible utilizar integración continua se pueden utilizar builds diarios o frecuentes.
Tiene beneficios no sólo en cuanto a encontrar conflictos sino también porque fomenta la calidad de las pruebas unitarias.
As compilation is a computationally intensive process, tools to support system building may be designed to minimize the amount of compilation that is required.
They do this by checking if a compiled version of a component is available. If so, there is no need to recompile that component.
This linking is accomplished by associating a unique signature with each file where a source code component is stored.
Two types of signature may be used:
Pretende asegurar que la evolución del sistema es un proceso gestionado y que se priorizan los cambios urgentes y beneficiosos.
El proceso de gestión de cambios abarca analizar los costos y beneficios de las peticiones de cambio, aprobar los cambios e identificar los componentes que deben ser modificados.
Many variants of this process are in use depending on whether the software is a custom system, a product line, or an off-the-shelf product. However, all change management processes should include some way of checking, costing, and approving changes.
Tools to support change management may be relatively simple issue or bug tracking systems or software that is integrated with a configuration management package for large-scale systems.
Issue tracking systems allow anyone to report a bug or make a suggestion for a system change, and they keep track of how the development team has responded to the issues.
The change management process is initiated when a system stakeholder completes and submits a change request describing the change required to the system.
This could be a bug report, where the symptoms of the bug are described, or a request for additional functionality to be added to the system.
Change requests may be submitted using a change request form (CRF).
After a change request has been submitted, it is checked to ensure that it is valid.
The change request may be rejected at this stage.
In that case, the issue is closed and the form is updated with the reason for closure.
For valid change requests, the next stage of the process is change assessment and costing.
The impact of the change on the rest of the system must be checked.
Finally, the cost of making the change is estimated, taking into account the costs of changing related components.
Following this analysis, a separate group decides if it is cost-effective for the business to make the change to the software.
A group should review and approve all change requests, unless the changes simply involve correcting minor errors on screen displays, web pages, or documents.
These small requests should be passed to the development team for immediate implementation.
El comité de control de cambios debe analizar cada cambio teniendo en cuenta:
En algunas metodologías ágiles, el cliente está directamente involucrado en la gestión de los cambios.
Considerar la propuesta de cambios a requerimientos, evaluar el impacto y decidir cuando la modificación tiene prioridad sobre las características planificadas para el siguiente incremento del sistema.
Los cambios para mejorar el software son decididos por los programadores que trabajan en el sistema.
Refactorizar, no es visto como una sobrecarga sino como una parte del proceso de desarrollo.
Una liberación corresponde a una versión (del software) que queda liberada para su uso.
For mass-market software, it is usually possible to identify two types of release: major releases, which deliver significant new functionality, and minor releases, which repair bugs and fix customer problems that have been reported.
The release may also include:
For planning a release:
Release creation is the process of creating the collection of files and documentation that include all components of the system release.
This process involves several steps:
For custom software or software product lines, the complexity of the system release management process depends on the number of system customers. Special releases of the system may have to be produced for each customer. Individual customers may be running several different releases of the system at the same time on different hardware.
A software company may have to manage tens or even hundreds of different releases of their software. Their configuration management systems and processes have to be designed to provide information about which customers have which releases of the system and the relationship between releases and system versions.
When a system release is produced, it must be documented to ensure that it can be re-created exactly in the future. This is particularly important for customized, long-lifetime embedded systems, such as military systems and those that control complex machines.
To document a release, you have to record the specific versions of the source code components that were used to create the executable code. You must keep copies of the source code files, corresponding executables, and all data and configuration files.
When planning the installation of new system releases, you cannot assume that customers will always install new system releases. New releases of the system cannot, therefore, rely on the installation of previous releases.
Simplifica la gestión de liberaciones y la instalación del sistema por parte de los clientes.
El desarrollador del sistema es responsable de remplazar la versión actual con una nueva liberación. La nueva versión queda disponible para todos los clientes.
La gestión de la configuración es la gestión de un sistema de software en evolución.
Al mantener un sistema, se crea un equipo de CM para asegurar que los cambios se incorporen al sistema de manera controlada y que se lleva registro de los cambios que se han implementado
Los principales procesos de gestión de configuración son la gestión de cambios, la gestión de versiones, el armado de sistemas y la gestión de liberaciones.
La gestión de versiones implica el seguimiento de las diferentes versiones de componentes de software a medida que se realizan cambios en ellas.
El armado de un sistema es el proceso de ensamblar los componentes del sistema en un programa ejecutable para operar en un sistema de computación determinado.
El software debería ser rearmado de forma frecuente y probado inmediatamente luego de armar una nueva versión. Esto facilita la detección de defectos y problemas que pueden haberse introducido desde el armado anterior.
La gestión de cambios implica evaluar las propuestas de cambios de los clientes del sistema y otras partes interesadas y decidir si es rentable implementarlas en una nueva versión de un sistema.
Las liberaciones del sistema incluyen el código ejecutable, datos, archivos de configuración y documentación.
El propósito es determinar la metadata de un ítem de configuración, de modo de identificarlo de forma única y especificar sus relaciones con el mundo exterior y otros ítems de la configuración.
Los beneficios y costos de la Gestión de la Configuración están relacionados al alcance y al grado del formalismo.
El alcance corresponde al número de objetos comprendidos en la gestión de la configuración.
El grado del formalismo es el control con el cual se realizan las tareas de la gestión de la configuración.
Es imposible determinar cual alcance o grado de formalismo es el mejor; sino que la elección depende de los requerimientos y las posibilidades.
En general hay un mínimo de inversión que permite evitar situaciones que serían muy costosas. Esto define un mínimo alcance que nos cubre para evitar desastres.
Producto / Proyecto / Organización
La gestión de versiones es fundamental en los equipos de desarrollo distribuidos y en desarrollo ágil. Para esto se usan herramientas de diversos tipos. En los sistemas grandes, siempre hay varias versiones en desarrollo, y la gestión de configuración es parte de la gestión de calidad. Uno de los términos usados es repositorio, una base de datos de versiones y metadata. El control de versiones buscar controlar lo que sucede cuando los desarrolladores toman componentes del repositorio común, los modifican en su workspace privado y luego los vuelven a poner.
Un sistema VC distribuido es Git. Este modelo tiene ciertas ventajas: provee un respaldo, permite trabajar offline y cada uno puede probar el sistema entero en su máquina. Este tipo de sistema es fundamental cuando varias personas trabajan sobre un mismo sistema. Se pueden crear varias ramas a partir del mismo código, luego hay que hacer merge. Para ahorrar espacio y no tener que almacenar varias copias de lo mismo, se pueden guardar deltas, que son las diferencias entre una versión y otra.
El tamaño y tipo de software influyen en el proceso de gestión de cambios (por ejemplo: quién sugiere los cambios, el cliente en software particular), pero todos tienen que comprobar, calcular costo y verificar los cambios. Hay que verificar que una solicitud de cambio sea válida (no puede hacerse si ya existe o es inválida). Luego se evalúa el impacto en el resto del sistema y el costo para ver si vale la pena. Esto lo hace el comité.
Por el tema de las diferentes versiones y de dónde provienen sus componentes, es importante que haya documentación para poder recrear el sistema. Hay que guardar la versión de todo lo usado.